Hallo, guten Morgen. Wir hatten das letzte Mal uns mit dem großen Themenkomplex Prozesse beschäftigt.

Ich hatte eine ganze Reihe über Prozesse, Prozessmodelle, leichtgewichtige Prozesse und Prozesse

SRETS, ein bisschen was über Scheduling erzählt. Ich wollte was über Koordinierung erzählen und

bin dann offensichtlich zum richtigen Zeitpunkt, habe ich mit der Maus aufs falsche Kapitel geklickt

und bin dann also völlig nahtlos zum Thema Interprozesskommunikation und

Kommunikationsmittel gesprungen und habe also diesen ganzen Themenkomplex mit der Koordinierung von

gleichzeitig Prozessen elegant übersprungen. Das muss man heute aber unbedingt noch nachholen,

diesen Teil 2 hier, denn der ist ganz essentieller Bestandteil der Übungsaufgabe,

die ab dieser Woche in den Übungen rankommt und sonst würde uns da ja doch was Wesentliches fehlen.

Ich will aber, damit wir nicht zu viel hin und her springen und nachdem wir das letzte Mal auch

diesen Teil 3 ja nicht ganz fertig gemacht haben, an der Stelle nochmal aufsetzen. Wir hatten da

letztendlich uns mit dem Botschaftenaustausch zwischen Prozessen, gegebenenfalls sogar über

Rechnergrenzen hinweg beschäftigt mit den verschiedenen Konzepten oder Semantiken,

die dahinter stecken und also im Wesentlichen diese drei hier, No-Way-Send, Synchronization-Send

und Remote-Invocation-Send, die drei Konzepte im einen Fall, dass der Sender letztendlich nur

wartet bis die Nachricht im Transportsystem ist, im zweiten Fall, dass der Sender wartet bis die

Nachricht beim Empfänger angekommen ist und im dritten Fall, dass er auch auf eine Antwort wartet.

Der dritte Fall ist in der Praxis eigentlich der interessanteste, denn nachdem dieses Verhalten an

der Stelle von der Semantik eigentlich wie ein Prozeduraufruf aussieht, ein Prozeduraufruf ist ja

auch, man macht einen Aufruf, die Prozedur arbeitet ab und schickt eine Antwort, nämlich den

Return-Wert zurück und nachdem das vom Konzept her eigentlich ziemlich identisch ist, ist das also

ein Konzept, das sehr weit verbreitet ist in Form des Fernaufrufs oder Remote-Procedure-Calls und

ja ich hatte glaube ich auch erwähnt, also wer sich dafür näher interessiert, wir haben eine

Vorlesung auf verteilte Systeme im Vertiefungsbereich und da werden wir uns mit solchen Sachen und all

den Eigenheiten, die da dahinter stecken und was es sonst eben noch so alles in der Kommunikation

über Rechnergrenzen hinweg gibt, näher beschäftigen. So, der letzte oder geendet habe ich in der

letzten Woche mit der Fragestellung, mit wem kommuniziert man eigentlich überhaupt, also

wer ist der Adresspartner, die Senke, das Ziel der Interprozesskommunikation, wie adressiere ich

diesen Kommunikationspartner. Wenn ich mit einem Prozess oder einem Thread kommuniziere, könnte ich

natürlich letztendlich die Prozessidentifikation dieses Threads nehmen und im lokalen Fall, gerade

dann, wenn es mehrere Threads innerhalb von einem Prozess sind, ist das auch ein relativ adäquates

Mittel. Wenn es mehrere verschiedene Prozesse sind, dann ist das noch ein adäquates Mittel,

wenn diese Prozesse irgendwie miteinander verwandt sind, wenn also der eine Prozess den anderen

erzeugt hat. Dann hat er ja beim Fork die Prozess-ID sowieso als Ergebnis bekommen und dann könnte

er natürlich genau an diesen Prozess etwas schicken. Man macht das in der Praxis ja durchaus auch,

zum Beispiel, wenn man Signale verschickt, dass man genau dieses Konzept verwendet. Im allgemeinen

Fall, gerade wenn es voneinander unabhängige Prozesse sind, ist das keine besonders gute Idee,

vor allem dann eben auch, wenn der Prozess einfach noch den Dienst anbietet, denn woher kennt man die

Prozess-ID überhaupt. Und das Wesentliche ist ja auch, Prozesse können terminieren,

Prozesse können neu gestartet werden und jedes Mal bekommen sie eine neue Prozess-ID. Das heißt,

die Prozess-ID ist eigentlich keine eindeutige Identifikation. Die Idee ist dann eher, mit dem

Dienst letztendlich einen Identifikator zu verbinden, das sind die sogenannten Ports und

im Falle von der Interprozesskommunikation über Rechnergrenzen, also gerade bei TCPIP,

sind diese Portnummern auch etwas, was durchaus normiert wird. Da gibt es also bei Standardisierungsgremien

Ausschüsse, in denen solche Portnummern für bestimmte Dienste festgelegt werden. Wenn man also

einen allgemeinen etablierten Dienst einrichten möchte, dann will man natürlich letztendlich

eine Standardportnummer dafür haben. Der bekannteste Fall davon ist sicherlich der Port 80 für den

HTTP-Dienst und dass eben der Port 80 für HTTP-Diemens zur Verfügung steht, das ist irgendwo auch mal

festgelegt worden und außer irgendwelche Testserver, jeder Standard-HTTP-Server arbeitet

eben auf Port 80 und ist dort erreichbar. Und dann gibt es letztendlich in dem Rechner eine